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(54) Central policy based traffic management 

(57) A switching node configuring different traffic 
management protocols via a single centralized set of 
policies. The switching node includes a central policy 
repository, a central policy engine, and a central man- 
agement engine. The central policy repository stores a 
single set of policies used to manage a plurality of dif- 
ferent traffic management protocols in a consistent and 
predictable manner. The different traffic management 



protocols may include QoS, NAT, ACL, and the like. The 
central policy Mgine evaluates inbound traffic Hows 
based on the plflcies in the central policy repository, and 
configures onaioj' more traffic management protocol en- 
tities based on a selected policy. The management en- 
gine configures and manages the single sot of policies 
via a common set of commands helping to eliminate iho 
danger of creating conflicting policies that may load to 
unpredictable results. 
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Description 

CROSS-REFERENCE TO RELATED APPLICATION 

(S) 

[0001] This application claims the benefit of U.S. pro- 
visional application No. 60/328,159, filed on October 10, 
2001 , the content of which is incorporated herein by ref- 
erence. 

FIFTD Or THE INVENTION 

[0002] Tho present invention relates generally to traf- 
fic control in a data communications network, and more 
particularly, to configuring different network protocols 
associated with traffic management via a single central- 
ized set of policies. 

BACKGROUND OF THE INVENTION 

[0003] Policy based traffic control has become in- 
creasingly important in data communication networks 
as data traffic competes for limited bandwidth. Policy 
based traffic control generally involves separate, inde- 
pendent interfaces for configuring different traffic man- 
agement protocols. 

[0004] FIG. 1 is a schematic block diagram of a 
switching nodo 9 for policy based traffic control accord- 
ing to conventional mechanisms. The switching node in- 
cludes separate, independent policy engines 11, 13, 15 
and associated interfaces 17, 19, 21 for managing and 
configuring different traffic management protocols. For 
example, a switching node may include a separate pol- 
icy engine for controlling quality of service (QoS), IP fil- 
tering via access control lists (ACL), network address 
translation (NAT), and the like. Each policy engine is as- 
sociated with a control interface used by a network ad- 
ministratorta configure and manage the associated pol- 
icies for a discrete traffic management protocol. 
[0005] In general terms, an inbound packet is proc- 
essed by a first policy engine, such as, a QoS policy 
engine, for a matching policy. If a match is found, the 
matching policy is enforced and the packet is generally 
not processed by the other policy engines. If a match is 
not found, the packet is processed by a next policy en- 
gine for a match. Under existing technology, therefore, 
multiple actions from different policy engines are either 
impossible or difficult to perform for a specific traffic flow. 
It is often desirable, however, to be able to perform such 
multiple actions. For example, it may be desirable to in- 
voke a NAT policy engine for address translation based 
on a source IP address while simultaneously invoking 
the QoS policy engine for assigning a QoS priority to the 
(low based on the same source address. 
[0006] Another problem with the current policy based 
traffic control is that the use of separate, independent 
interfaces for configuring the policies generally requires 
the network administrator to learn and use different 



command sequences for configuring and managing dif- 
ferent policy engines. This may result in the configura- 
tion of conflicting policy rules that may leadto unpredict- 
able results, especially if the configurations are done by 
s different administrators or the same administrator at dif- 
ferent times. 

[0007] Accordingly, there is a need for a mechanism 
for providing and applying a common and consistent set 
of policies to traffic flowing through a data communica- 
io tions network. The mechanism should allow aswitching 
node to enforce a singe policy with multiple actions in a 
consistent manner. 

SUMMARY OF THE INVENTION 

15 

[0008] The present invention is directed to traffic man- 
agement via a single centralized set of policies. Accord- 
ing to one embodiment, the invention is directed to a 
switching node in a data communications network that 

20 includes an input, a repository, a policy engine, and a 
management engine. The repository stores a single set 
of policies for controlling a plurality of different traffic 
management protocols. The policy engine is coupled to 
the input and the repository, and is configured to evalu- 

25 ate an inbound packet based on a policy selected from 
the single set of policies, and configure one or more traf- 
fic management protocol entities based on the selected 
policy. The management engine is coupled to the repos- 
itory and the policy engine. The management engine 

30 configures and manages the single set of policies via a 
common set of commands. 

[0009] According to another embodiment, the inven- 
tion is directed to a method for policy based traffic man- 
agement where the method includes storing in a repos- 

35 itory a single set of policies for controlling a plurality of 
different traffic management protocols. The method in- 
cludes receiving a first packet, retrieving a first policy 
from the repository where the first policy identifies a first 
action for configuring a traffic management protocol en- 

io tity of a first protocol type, and configuring the traffic 
management protocol entity based on the first action. 
The method also includes receiving a second packet, 
retrieving a second policy from the repository where the 
second policy identifies a second action for configuring 

45 a traffic management protocol entity of a second proto- 
col type, and configuring the traffic management proto- 
col entity based on the second action. 
[0010] According to a further embodiment, the inven- 
tion is directed to a method for policy based traffic man- 

50 agement where the method includes storing in a repos- 
itory a single set of policies for controlling a plurality of 
different traffic management protocols, receiving a 
packet, and retrieving a policy from the repository which 
identifies a first and second action for controlling traffic 

ss management protocol entities of a first and second pro- 
tocol type. The method includes configuring the traffic 
management protocol entity of the first protocol type 
based on the first action and configuring the traffic man- 
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agement protocol of the second protocol type based on 
the second action. 

[0011] In an additional embodiment, the invention is 
directed to a method for policy based traffic manage- 
ment where the method includes storing in a repository s 
a single set of policies for controlling a plurality of differ- 
ent traffic management protocols, receiving a packet, 
and searching a policy cache for a policy applicable to 
the packet. If the policy cache does not include an ap- 
plicable policy, the method includes searching the re- « 
pository for a match, and generating and storing a new 
policy in the policy cache. The new policy is selected as 
applicable to a future packet if the repository contains 
no other policies that are also applicable to a future 
packet but are different from the new policy. n 
[0012] It should be appreciated, therefore, that the 
evaluation of traffic via a central policy engine allows the 
configuration of traffic management protocol entities of 
different protocol types, such as quality of service, ac- 
cess control, network address translation, and the like, 2C 
in a consistent and predictable manner. The manage- 
ment of the policies via a common set of commands and 
the storage of the policies in a central repository help 
eliminate the creation and application of conflicting pol- 
icies that could result in unpredictable results. 25 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0013] These and other features, aspects and advan- 
tages of the present invention will be more fully under- 30 
stood when considered with respect to the following de- 
tailed description, appended claims, and accompanying 
drawings where: 

FIG. 1 is a schematic block diagram of a switching 35 
node for policy based traffic management according 
to conventional mechanisms; 
FIG. 2 is a schematic block diagram of a network 
environment including a packet switching node ac- 
cording to one embodiment of the invention; 40 
FIG. 3 is a block diagram of a switching interface in 
one embodiment of the present invention; 
FIG. 4 is a schematic block diagram of the packet 
switching controller providing and applying a com- 
mon, centralized set of simple policies for control- 45 
ling a plurality of traffic management protocols ac- 
cording to one embodiment of the invention; 
FIG. 5 is a more detailed diagram of the switching 
controller of FIG. 4 according to one embodiment 
of the invention; 50 
FIG. 6 is a conceptual layout diagram of various 
types of policy objects provided by a central man- 
agement engine for creating a centralized set of pol- 
icies according to one embodiment of the invention; 
FIG. 7 is a conceptual layout diagram of a central 55 
policy repository according to one embodiment of 
the invention; and 

FIG. 8 is a flow diagram of a central policy based 



traffic management according to ono embodiment 
of the invention. 

DETAILED DESCRIPTION 

[0014] FIG. 2 is a schematic block diagram of a net- 
work environrnji it including a packet switching node 1 0 
according to ft\e embodiment of the invention. The 
packet switching) node may also be referred to as a 
switch, adataiftmmunication node or a data communi- 
cation switch. Tie packet switching node 10 includes 
switching inten^ ;es 1 4, 1 6 and 1 8 interconnected to re- 
spective groups 5f LANs 30, 32, 34, and interconnected 
to one another Over data paths 20, 22, 24 via switching 
backplane 12. The switching backplane 12 preferably 
includes switching fabric. The switching interfaces may 
also be couplajt) to one another over control paths 26 
and 28. 

[0015] The switching interfaces 14, 16, 18 preferably 
forward packeljs jto and from their respective groups cf 
LANs 30, 32, 3(4:|in accordance with one or more oper- 
ative communication protocols, such as, for example, 
media access control (MAC) bridging and Internet Pro- 
tocol (IP) routihg. The switching node 10 is shown for 
illustrative purpoises only. In practice, packet switching 
nodes may include more or less than throe switching 
interfaces. 

[0016] FIG. 3 Is a block diagram of a switching inter- 
face 50 in one embodiment of the present invention . The 
switching interface 50 may be similar, for example, to 



the switching 
ing interface 
pled between 
52. The acces: 
include a medi 



wlacesU, 16, 1 8 of FIG. 2. Tho switch- 
[(deludes an access controller 54 cou 
*ls and a packet switching controller 
I Ctontroller 54, which may, for oxamplo, 
i Siccess controller (MAC), preferably re- 
ceives inbound packets off LANs, performs flow-inde- 
pendent physical and MAC layer operations on the in- 
bound packets and transmits the inbound packets to the 
packet switching controller 52 for flow-depondont 
processing. The access controller 54 also receives out- 
bound packets from the packet switching controller 52 
and transmits the packets on LANs. The access control- 
ler 54 may also; perform physical and MAC layer oper 
ations on the outbound packets prior to transmitting 
them on LANs. 

[0017] The packet switching controller 52 receives in- 
bound packets, classifies the packets, modifies the 
packets in accordance with flow information and trans 
mits the modified packets on switching backplane, such 
as the switching backplane 12 of FIG. 2. The packet 
switching controller 52 preferably also receives packets 
modified by other packet switching controllers via the 
switching backplane and transmits them to the access 
controller 54 forfdrwarding on LANs. The packet switch- 
ing controller 52 nay also subject selected ones of the 
packets to egress! processing prior to transmitting them 
to the access controller 54 for forwarding on LANs. 
[0018] FIG. 4 is a schematic block diagram of the 
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packet switching controller 52 providing and applying a 
common, centralized set of simple policies for coordi- 
nating a plurality of traffic management protocols, such 
as, for example, access control, address translation, 
server load balancing, quality of service, and the like. 
The switching controller 52 includes a central policy en- 
gine 56 coupled to a central management engine 58. 
The central policy engine 56 evaluates the traffic flow 
against the centralized set of policies to perform, from 
a central location, one or more policy actions typically 
performed by separate, independent policy engines. 
I he centralized set of policies include, but are not limited 
to system policies, network policies, access policies, 
services policies, and the like. The one or more actions 
include, but are not limited to packet filtering, packet pri- 
oritizing, address translation, server load balance group 
assignment, and assignment of 802. 1p. TOS, or DSCP 
values. 

[0019] The central management engine 58 may in- 
clude software and/or hardware components to enable 
a network administrator to configure and manage the 
centralized set of policies, With the central management 
engine 58, the network administrator may, from a single 
location and using a common set of commands, create 
policies that manage different traffic management pro- 
tocols. 

[0020] FIG. 5 is a more detailed diagram of theswitch- 
ing controller 52 according to one embodiment of the 
invention The switching controller includes a packet 
buffer 102, packet classification engine 104, central pol- 
icy engine 106, central policy enforcement engine 120, 
central policy repository 100, and central management 
engine 107. The packet classification engine 104, cen- 
tral policy engine 106, central policy enforcement en- 
gine 120, and central policy management engine 107 
arc logical devices that may be implemented in soft- 
ware, hardware, firmware (e.g. ASIC), or any combina- 
tion thereof. It is understood, of course, that FIG. 5 illus- 
trates a block diagram of the packet switching controller 
without obfuscating inventive aspects of the present in- 
vention with additional elements and/or components 
that may be required for creating the controller. These 
additional elements and/or components, which are not 
shown in FIG. 5 are well known to those skilled in the art. 
[0021] The switching controller 52 receives inbound 
packets 1 08. The packets may include, but are not lim- 
ited to, Ethernet frames, ATM cells, TCP/IP and/or UDP/ 
IP packets, and may also include other Layer 2 (Data 
Link/MAC Layer), Layer 3 (Network Layer) or Layer 4 
(Transport Layer) data units. 

[0022] The received packets are stored in the packet 
buffer 102. The packet buffer 102 provides via output 
signal 1 1 0 the stored packets or portions thereof to the 
packet classification engine 104 for processing. 
[0023] The packet classification engine 104 may in- 
clude one or more of a data extractor and a data cache. 
In an alternative embodiment, the data extractor and da- 
ta cache are provided within the packet buffer 1 02. 



[0024] The data extractor is used to extract one or 
more fields from the packets, and to store the extracted 
fields in the data cache as extracted data. The extracted 
data may include, but is not limited to, some or all of the 

s packet header. For example, the extracted data may in- 
clude, but are not limited to, one or more of Layer 2 MAC 
addresses, 802.1 P/Q tag status, Layer 2 encapsulation 
type, Layer 3 protocol type, Layer 3 addresses, ToS 
(type of service) values, Layer 4 port numbers, portions 

10 of the packet body, and/or any other data used for de- 
termining a policy, 

[0025] The extracted data is transmitted to the central 
policy engine 106 via an output signal 112. The central 
policy engine 106 may be similar to the central policy 

'5 engine 56 of FIG. 4. 

[0026] The central policy engine 106 accesses either 
an internal policy cache 1 1 6 or the central policy repos- 
itory 100 for selecting a policy applicable to the packet. 
In accessing the central policy repository 1 00, the cen- 

20 tral policy engine 106 communicates with the repository 
using protocols such as, for example, LDAP. 
[0027] According to one embodiment of the invention, 
the policy cache 116 includes sufficient information for 
applying policies to existing traffic flows without having 

25 to process the entire list of policies in the central policy 
repository 100 for every packet in the traffic flow. The 
information in the policy cache 1 1 6 is specific enough to 
prevent packets for which a different applicable rule may 
exist in the central policy repository 1 00 to be processed 

so by the policy cache 116. 

[0028] The central policy repository 100 may be im- 
plemented in a local memory and/or an external direc- 
tory server with Lightweight Directory Access Protocol 
(LDAP) access. The central policy repository 100 In- 

35 eludes a list of policies that are based on the contents 
of a packet and/or other elements such as, for example, 
time information, port information, and the like. In gen- 
eral terms, policies are rules composed of one or more 
conditions that describe a packet and one or more ac- 

40 tions defining how the packet is to be processed if the 
condition is satisfied. 

[0029] The central policy engine 106 compares the 
extracted packet data with either the policies in the pol- 
icy cache 116 or central policy repository 100. If a match 

45 is found between the condition(s) in the policy and the 
extracted data, the policy engine determines the action 
(s) to be taken on the packet. The action(s) to be taken 
on the packet are transmitted to the central policy en- 
forcement engine 120 via an output signal 11 7. 

so [0030] The central policy enforcement engine 120 en- 
sures that the packet is processed according to the pa- 
rameters defined in theaction(s), In this regard, the cen- 
tral policy enforcement engine 120 interacts with other 
hardware and software elements in the switching node 

55 30 for causing a desired processing of the packet. For 
example, if the policy actions specify that the packet is 
to be transmitted at a high priority, the policy enforce- 
ment engine 120 may direct the packet buffer 102 to 



4 



7 



EP 1 303 079 A2 



8 



place the packet in a high priority queue of an egress 
port. 

[0031 ] The central management engine 1 07 of FIG. 5 
may be similar to the central management engine 58 of 
FIG. 4. The engine 1 07 may be either a dedicated con- 
sole or part of a network management console. A net- 
work administrator accesses the central management 
engine 1 07 for configuring and managing the policies in 
the central policy repository 100 and the central policy 
engine 106. According to one embodiment, the central 
management engine 107 provides a graphical user in- 
terface that provides a common set of commands and 
tools for configuring and managing polices that control 
different network elements such as, for example, QoS, 
NAT, ACL, and the like. The central management engine 
107 also allows a network administrator to test policies 
before they are applied. 

[0032] FIG. 6 is a conceptual layout diagram of vari- 
ous types of policy objects provided by the central man- 
agement engine 1 07 for creating the centralized set of 
policies according to one embodiment of the invention. 
In the illustrated embodiment, the policy objects include 
rule 200 objects, condition 202 objects, action 204 ob- 
jects, service 206 objects, and group 208 objects. Rules 
200 are top level objects including conditions 202 and 
actions 204. According to one embodiment, rules; are 
provided precedence values indicative of an order in 
which the rules are to be applied, 
[0033] Conditions 202 are parameters used to classi- 
fy traffic, and actions 204 are parameters describing 
how to treat the classified traffic. A condition 202 may 
include a service 206 and/or a group 208. A policy serv- 
ice 206 may be used as a shorthand for certain parts of 
a condition, According to one embodiment, a policy 
service 206 is defined by a service name, an I P protocol, 
a source IP port, and/or a destination IP port. For exam- 
ple, a "video" service may be defined as being associ- 
ated with a "UDP" protocol and destination IP port 
number "4500." In another example, a "telnet" service 
may be defined as being associated with a 'TCP" pro- 
tocol and destination IP port number "23." 
[0034] A policy group 208 may be defined by a list of 
IP/MAC addresses, ports, or services. Policy groups al- 
low a network administrator to define conditions for a 
group of address, ports, or services, instead of creating 
a separate condition for each address, port, or service. 
For example, an "engineering" group may be defined as 
a set of particular IP addresses. A "basic services" group 
may be defined as a set of particular services such as 
telnet, FTP, HTTP, and Sendmail. 
[0035] According to one embodiment of the invention, 
the central management engine 1 07 allows the creation 
of policies defining multiple actions for managing differ- 
ent traffic management protocols. For example, a policy 
in the central policy repository 1 00 may indicate that traf- 
fic with a particular source address and a particular des- 
tination address is to have the source address translat- 
ed and receive a high priority. Thus, two different ac- 



tions, a NAT policy action and a QoS policy action, may 
be defined via a (single policy rule. FIG. 7 is a conceptual 
layout diagram of :ho central policy repository 100 ac 
cording to one embodiment of the invention, in th s il us 
s trated embodiment, the repository includes a policy :a 
ble 300 including a list of simple policy rules 30? Asso 
ciated with each policy rule are a precedence nLmber 
304, condition 306, and action 308, The nrcccdcncc: 
number 304 indicates an order in which :ho rules are te 
10 be applied If traffic matches more than one r.jle l ie 
central policy engne 106 uses the rule with ire highest 
precedence. In the illustrated embodiment, rule is col 
matched since it is a subset, or more specific, than the 
higher precedence rule 2. The precedence ordering of 
's the rules helps! eliminate any rule conflicts and ensures 
that the results <>f evaluating a traffic flow against the 
policies is predictable and consistent. 
[0036] The condition 306 for each rule defines param 
eters used for classifying inbound packets. These pa 
20 rameters include but are not limited to individual source 
addresses orgolirce address groups, individual desti- 
nation addresses or destination groups, and individual 
IP protocols 36flfe, individual IP ports 306d, or policy 
service groups 3D6c. 
25 [0037] The action 308 for each rule defines one or 
more operatioqs.jto be performed on the packet and/or 
traffic management protocol entities. The action 308 
may be a filtering action, such as for example, dropping 
or admitting a packet. The action 308 may also be a QoS 
30 action such as, for example, assigning a priority to the 
packet. The acftain 308 may further bo server load bal- 
ancing, sourcejlf destination address translation, map- 
ping ormarkinJflp2.1 P.TOS, or DSC P values, or a com- 
bination of any of the discussed actions. 
35 [0038] FIG. 8 Is a flow diagram of a central policy 
based traffic control according to one embodiment of the 
invention. The process starts, and in stop 400, the pack 
et buffer 102 receives an inbound data packet and 
stores the packet in the buffer In step 402, the packet 
40 classification engine 104 extracts one or more fields 
from the packets. In step 404, the central policy engine 
106 determines Whether the policy cache contains en- 
tries that match the extracted fields of the packet If the 
answer in YES, the central policy enforcement engine 
*s 120 ensures that the policy action indicated in the 
matched entry of the policy cache is enforced. 
[0039] If no match exists in the policy cache 116, the 
central policy engine 1 06 determines in stop 408 whet h 
er there is an exact match of the extracted fields with 
so conditions of a rule in the central policy repository 100 
If the answer is YES, the central policy engine proceeds 
to program, in step 414, the policy cache 116 with the 
condition fields of the matched policy, the fields having 
the values of the corresponding extracted fields. I his 
55 allowsfuturedatapackets with the same extracted fields 
to match the newly programmed ontry in the policy 
cache 116, avoiding another search of the central policy 
repository 100. In step 416, the central policy enforce 
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mcnt engine 1 20 proceeds to take the policy actions in- 
dicated in the matched policy rule. 
[0040] If there is no exact match of the conditions of 
a rule in the central policy repository 100, a determina- 
tion is made in stop 41 0 whether a partial match exists. 
11 the answer is YES, the central policy engine 106 pro- 
ceeds to program the policy cache 116 in step 418 with 
the condition fields of the selected policy, the fields hav- 
ing the values of tho corresponding extracted fields, and 
with a default action. In step 420, the central policy en- 
forcement engine 120 proceeds to take the default pol- 
icy action. 

[0041] If the search of the central policy repository 100 
does not result in even a partial match of the rules, the 
central policy engine 106 proceeds to program the pol- 
icy cache 116, in step 412, with minimal information 
needed to forward the packet. According to one embod- 
iment of tho invention, such minimal information is a 
source address of tho packet, a destination address of 
tho packet, and a default policy action. In another em- 
bodiment of tho invention, the minimal necessary infor- 
mation is simply tho destination address and the default 
policy action. Tho default policy action is enforced by 
the central policy enforcement engine 120 in step 420. 
[0042] The programming of the policy cache 1 1 6 will 
bo best understood when considering the following ex- 
ample. Assume that the central policy repository 1 00 in- 
cludes tho rules depicted in FIG. 7. 
[0043] A first packet received by the central policy en- 
gine 106 Includes the following fields extracted by the 
classification engine 104: 

Source IP - 192.200.200.200 
Destination IP - 10.5.3.4 
Protocol - TCP 
Port - 80 (HTTP) 

[0044] The central policy engine 106 compares the 
extracted information with entries in the policy cache 
116. Assuming for purposes of this example that this is 
a first packet processed by the central policy engine 
106. no entries are contained in the policy cache 116. 
[0045] The central policy engine 106 then proceeds 
to search tho central policy repository 100 for a match. 
Upon a finding of no match in the central policy reposi- 
tory 100, tho central policy engine programs the policy 
cache with a minimal amount of information needed to 
process and forward future similar packets. In one ex- 
ample, tho central policy engine may program the policy 
cache with a source IP address, destination IP address, 
and a default action. The default action in this example 
is tho assignment of a default priority. The entry placed 
in the policy cache is as follows: 

Source IP -192.200.200.200 
Destination IP - 10.5.3.4 
Action - 0 (best effort priority) 



[0046] The central policy engine 1 06 next receives a 
packet that includes the following fields: 

Source IP - 192.200.200.200 
s Destination IP- 192.1 6B. 1.1 
Protocol - TCP 
Port - 80 (HTTP) 

[0047] The central policy engine 106 compares the 
io extracted information with entries in the policy cache 
1 1 6. Upon a no match, the extracted information is com- 
pared against the rules in the central policy repository 
100. Rule 1 matches the packet's source IP address, 
destination IP address, and protocol. However, there is 
is no match in the port information, resulting in a partial 
match with rule 1. 

[0048] In determining an entry for the policy cache, 
the central policy engine 106 ensures that the entry is 
specific enough to prevent packets for which a different 

20 applicable rule may exist in the central policy repository 
1 00 to be processed by the policy cache. In this regard, 
the central policy engine 1 06 determines the number of 
condition fields of the rule that resulted in the partial 
match. Rule 1 that resulted in the partial match includes 

25 four condition fields: source IP address, destination IP 
address, protocol and port. Thus, the entry placed in the 
fast path includes four condition fields although only the 
source IP and the destination IP are needed to forward 
future packets. The value of the four fields is based on 

30 the information extracted from the packet. Accordingly, 
the entry placed in the policy cache is as follows: 

Source IP - 192.200,200.200 
Destination IP - 192.168,1.1 
35 Protocol - TCP 
Port - 80 (HTTP) 
Action - 0 (best effort priority) 

[0049] A next packet received by the central policy en- 
40 gjne 1 06 includes the following fields: 

Source IP - 192.200.200.200 
Destination IP - 192.168.1.1 
Protocol - TCP 
« Port -21 (FTP) 

[0050] The central policy engine 106 compares the 
extracted information with entries in the policy cache 
116 and does not find a match. If, however, the policy 

so cache had been programmed with less than four fields 
in processing the previous packet, a match would have 
resulted in the policy cache, causing the current packet 
to the forwarded without consulting the rules in the cen- 
tral policy repository. 

55 [0051] The central policy engine 106 proceeds to 
search the central policy repository 1 00 and finds an ex- 
act match with rule 1. In determining the entry to be pro- 
grammed in the policy cache, the central policy engine 
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positoiy, the policy engine evaiualing the pack 
et based on a policy selected from the single 
set of policies and configuring one or more traf- 
fic management protocol entities based on the 
selected policy; and 

a management engine coupled to the reposi- 
tory andJthe policy engine, the management en 
gine configuring and managing the single set of 
policieto Via a common set of commands. 

2. The switching node of claim 1 . wherein the single 
set of policies includes a policy identifying two or 
more actions for controlling two or more traffic man 
agement protocols. 

3. The switchjrtg node of claim 1 . wherein the single 
set of policies includes afirst policy identifying a first 
action for qoiitrolling a first traffic management pro 
tocol and a second policy identifying a second ac- 
tion for controlling a second traffic management 
protocol. f!i] 

4. The switchjJifg node of claim 1 , wherein one of the 
traffic nnant»jjjement protocols is quality of service 

5. The switching node of claim 1 , wherein one of the 
traffic nnanajjjement protocols is access control 

6. The switching node of claim 1 , wherein one of the 
traffic management protocols is address transla 
tion. 

7. The switching node of claim 1 further comprising a 
policy cacte coupled to the repository and the pol- 
icy engine for storing a plurality of cached policies. 

8. The switching node of claim 7. wherein the policy 
engine is configured to evaluate the packet based 
on the plurality of cached policies prior to evaluating 
the packet based on the policies in the repository. 

9. The switching node of claim 8, wherein the central 
policy engine selects a cached policy as applicable 
to the packet if no other policies are stored in the 
repository that are also applicable to the packet but 
are different from the selected cached policy 



determines the number of condition fields in the rule that 
resulted in the exact match. The four condition fields of 
the matching rule 1 are then programmed into the policy 
cache. The value of the four fields is based on the infor- 
mation extracted from the packet. The entry placed in 
the policy cache is as follows: 

Source IP - 192.200.200.200 
Destination IP - 192.168.1.1 
Protocol - TCP 
Port -21 (FTP) 
Action - 7 (high priority) 

[0052] The central policy engine 106 next receives a 
packet that includes the following fields: 

Source IP - 192.200.200.200 
Destination IP - 192.168.2.2 
Protocol - UDP 
Port - 300 

[0053] The central policy engine 106 compares the 
extracted information with entries in the policy cache 
1 1 6 and does not find a match. The central policy engine 
106 then proceeds to search the rules in the central pol- 
icy repository 100 and finds an exact match with Rule 
2. The fields in Rule 2 that resulted in the exact match 
are source IP address and destination IP address. Ac- 
cordingly, the entry placed in the policy cache is as fol- 
lows: 

Source IP - 1 92.200.200.200 
Destination IP - 192.168.2.2 
Action - 7 (high priority) 

[0054] Although this invention has been described in 
certain specific embodiments, those skilled in the art will 
have no difficulty devising variations which in no way 
depart from the scope and spirit of the present invention. 
It is therefore to be understood that this invention may 
be practiced otherwise than is specifically described. 
Thus, the present embodiments of the invention should 
be considered in all respects as illustrative and not re- 
strictive, the scope of the invention to be indicated by 
the appended claims and their equivalents rather than 
the foregoing description. 



Claims 

1. A switching node in a data communications, net- 
work, the switching node comprising: 

an input receiving an inbound packet; 
a repository storing a single set of policies for 
controlling a plurality of differenttraffic manage- 
ment protocols; 

a policy engine coupled to the input and the re- 



10. The switching node of claim 8, wherein if no match 
of a policy is found in the repository, the policy en 

so gine is configured to store in the policy cache a pol- 
icy having a destination address of the packet and 
a default action. 

11. The switching node of claim 8, wherein if a partial 
55 match of a policy is found in the repository, the pol- 
icy engine:!? configured to store in the policy cache 
a policy having condition fields of the policy in the 
-epositoryWhere the values of the condition fields 
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arc obtained from the packet, and a default action. 

The switching node of claim 8, wherein if a complete 
match of a policy is found in the repository, the pol- 
icy engine is configured to store in the policy cache 5 
a policy having condition fields of the policy in the 
repository where the values of the condition fields 
are obtained from the packet, and an action indicat- 
Dd by the policy in the repository. 

10 

A method for policy based traffic management com- 
prising: 

storing In a repository a single set of policies for 
controlling a plurality of different traffic manage- '5 
mcnt protocols; 
receiving a first packet; 

retrieving a first policy from the repository, the 
first policy identifying a first action for configur- 
ing a traffic management protocol entity of a so 
first protocol type; 

configuring the traffic management protocol of 
Iho first protocol type based on the first action; 
receiving a second packet; 
retrieving a second policy from the repository, 2$ 
the second policy identifying a second action 
for configuring a traffic management protocol 
entity of a second protocol type; and 
configuring the traffic management protocol en- 
tity of the second protocol type based on the so 
second action, 



searching the repository if the policy cache 
does not include an applicable policy; and 
generating and storing a new policy in the policy 
cache, 

wherein if the new policy is selected as applicable 
to a future packet, no policies are stored in the re- 
pository that are also applicable to the future packet 
but are different from the new policy. 

16. The method of claim 15, wherein if no match of a 
policy is found in the repository, the policy generat- 
ed and stored in the policy cache includes a desti- 
nation address of the packet and a default action. 

17. The method of claim 15, wherein if a partial match 
of a policy is found in the repository, the policy gen- 
erated and stored in the policy cache includes con- 
dition fields of the policy in the repository where the 
values of the condition fields are obtained from the 
packet, and a default action. 

18. The method of claim 15, wherein if a complete 
match of a policy is found in the repository, the pol- 
icy generated and stored in the policy cache in- 
cludes condition fields of the policy in the repository 
where the values of the condition fields are obtained 
from the packet, and an action indicated by the pol- 
icy in the repository. 



A method for policy based traffic management com- 
prising: 

35 

storing in a repository a single set of policies for 
controlling a plurality of differenttraffic manage- 
ment protocols; 
receiving a packet; 

retrieving a policy from the repository, the policy 40 
identifying a first and second action for control- 
ling a first and second traffic management pro- 
tocol entity, respectively, of a first and second 
protocol type, respectively; 
configuring the first traffic management proto- is 
col entity based on the first action; and 
configuring the second traffic management pro- 
tocol entity based on the second action. 



A method for policy based traffic management com- so 

prising: 



storing in a repository a single set of policies for 
controlling a plurality of differenttraffic manage- 
ment protocols; 55 
receiving a packet; 

searching a policy cache for a policy applicable 

to tho packet; 
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[57] ABSTRACT 

A scheduling apparatus and a scheduling method arc capable 
of reading data elements from a plurality of queues in such 
a form that past hysteresis reflects therein. The scheduling 
apparatus comprises a queue hysteresis table for storing .i 
value e_count obtained subtracting the number of data 
elements (packets, in a router) actually fetched out ol the 
queue, from the number of times with which this queue 
becomes a processing target with respect to each queue. The 
apparatus also comprises a scheduling unit lor cyclically 
designating each queue as a processing target, adding 1 h. 
e_count, corresponding to that queue, in the queue hvsu r 
esis table if no d»la elements exist in the queue designated 
as the processing target, consecutively fetching, from the 
processing target queue, the data elements the number ol 
which corresponds to a value of e count correspond inc to 
the queue if the data elements exist in the processing target 
queue, and decrementing the value of e count by tin 
number of fetched data elements. 

10 Claims, 13 Drawing Sheets 
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FIG. 8 is an explanatory diagram showing an outline of 
the queue hysteresis table incorporated into the router in a 
second embodiment; 

FIG. 9 is a flowchart showing operation procedures of the 
scheduling unil provided in the router in the second embodi- 
ment; 

FIG. 10 is an explanatory diagram showing an outline of 
the queue hysteresis table incorporated into the router in a 
third embodiment; 

FIG. 11 is a flowchart showing operation procedures of 
the scheduling unit provided in the router in the third 
embodiment; 

FIG. 12 is a diagram illustrating an example of internet 
working that uses the router; 

FIG. 13 is a block diagram showing functions of a router 
employing a prior art fair queuing method; and 

FIG. 14 is an explanatory diagram showing scheduling 
procedures by the router using the prior art fair queuing 
method. : 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

The present invention will hereinafter be specifically 
described with reference to the accompanying drawings. ; 
First Embodiment 

FIG. 1 illustrates an outline of a configuration of a router 
to which a scheduling method (and a scheduling apparatus) 
of the present invention is applied. A router 10 in a first . 
embodiment is an apparatus for connecting a subnet A to a 
subnet B, and includes, as shown in FIG. 1, a packet 
classifying unit 11, queues 12^12^, and output buffer 13, a 
queue hysteresis table 14 and a scheduling unit 15. Note that, 
the router 10 is constructed so that some queues 12 are . 
created in a memory dynamically in accordance with a 
receiving condition of packets. Therefore, queues 12 1 -12 / , 
are not always exist in the router 10. Although in this 
embodiment, assuming, for the sake of convenience, that the 
router 10 is provided with N queues 12 which functions 4 
independently, the configuration and operation will be dis- 
cussed first. Thereafter, real configuration and operation of 
the router 10 will be discussed. 

The queues 12j-12 w are buffers for temporarily storing 
packets that should be transmitted to the subnet B, and are A 
each made corresponding to transmitting stations (terminals) 
connected to the subnet A. The packet classifying unit 11 
supplies the queues 12 corresponding to transmitting 
addresses contained in those packets with packets received 
from the subnet A. Note that the router 10 in this embodi- 5 
ment is constructed so as to transfer packets (so-called 
internet packet) each having a structure shown in FIG. 2. 
Hence, the packet classifying unit It specifies a queue 12 to 
store the received packet by reading the transmitting termi- 
nal address (transmitting terminal IP address) included in the 5 
header of the received packet. 

Further, the packet classifying unit 11 executes a process 
of rewriting contents of the queue hysteresis table 14 (the 
details of which will be stated later on) in parallel to the 
above-described supplying process of the packets. The out- 6 
put buffer 13 is temporarily stored with the packets within 
the respective queues 12, and the packets in the output buffer 
13 are transmitted in the as-inputted sequence to the subnet 
B. 

The queue hysteresis table 14 is a table the contents of 6 
which are updated by the packet classifying unit 11 and the 
scheduling unit 15. As illustrated in FIG. 3, the queue 



hysteresis table 14 is stored with active Hags (a Hag) and 
empty count n)l»ibers (e__counf) in such a form ibul Uh-m: 
flags and numbers are made corresponding to queue IDs 
defined as data fr>r identifying the queues. 

The packet ! classifying unit 11 rewrites values of the 
active flags a_J(ag within the queue hysteresis table 1-1 in 
accordance with a packet receiving condition. More 
specifically, whesti receiving a packet, the packet classify! tie 
unit 11 reads, as shown in FIG. 4, a transmitting terminal 
, address included in the header of the received packet first 
(step S401). Nfjit, the packet classifying unit 11 specifies a 
queue ID for ^firing the received packet by referring to a 
address-queue |p table which holds the relationship between 
the transmitting ilerminal addresses and the queue IDs, and 
is provided insirle the unit (step S402). Thereafter, the packet 
' classifying unit 11 checks the value of the active lias- 
corresponding to the specified queue II) in the queue hvs 
teresis table 14 (step S403). 

When the value of the active flag is "(I" (step S403;N), I lie- 
packet classifying unit 11 rewrites the active Hag to " I " (step 
1 S404). Then, tlx: packet classifying unit 11 carries out a 
process for storing the received packet in the specilied queue 
12 (step S405). On the contrary, when the active flag is •• 1 " 
(step S403;Y), the packet classifying unit 11 carries nut a 
process for storing the received packet in the specified queue 
i 12 (step S405) without rewriting the active Hug. 

Moreover, the packet classifying unit 11, parallel to 
(independently on) the series of the above described 
processes, perfontns a process for managing receiving, lime 
of the last received packet for each queue II) the active lias 1 , 
i of which is set to "1". Then, the packet classifying unit II 
changes, based on the managing results, the active Hat', 
concerning the queue ID of which the receiving time 
becomes before a time which a predetermined time (such as 
60 sec.) is subHjjclcd from a current time to "0". 

The schedtl]|jjg unit 15 performs control to transmitting 
the packets stoifqe in the queues 12 to the output buffer 13. 
The scheduling tail 15, when executing this control, refers 
to values of the flags a__flag in the queue hysteresis table 14. 
and refers to and updates values of the empty count numbers 
e_count 

Operations of the router and the scheduling unit 15 in this 
embodiment will hereinafter be described specifically. 

FIG. 5 is a flowchart showing operation procedures ol tin: 
scheduling unit 15 after starting up the router. As shown in 
FIG. 5, the scheduling unit 15, when actuating this router. In 
begin with, sets. "1" in variables i and j respectively, and 
initializes the contents of the queue hysteresis table 14 (step 
S101). In step SUM, the scheduling unit 15 sets "0" in all ol 
the flags a_flag and of the empty count numbers e count, 
thereby initializing the queue hysteresis table 14. Moreovei. 
the packet classifying unit 11, after the scheduling unit 15 
has executed step S101, starts executing the above 
mentioned processes (of supplying the respective queues 
with the packets and updating the values of a Hag in (de- 
queue hysteresis table 14). 

After initializing the queue hysteresis table 14, the .sched- 
uling unit 15 judges whether an active Hag a Hag, of the 
queue the queue ID of which is i, is "1" or not (step SI 02). 

If a llagis not "If", (step S102; N), the scheduling unit 15 

executes a process (steps S120--S122) for setting the queue 
ID of the next queue in the variable i. That is, the scbedu linu. 
unit 15 compares the value of the variable i with a maximum 
value N of the queue ID and, if the value of the variable i is 
not coincident with N (step S120; N), adds "I" lo the 
variable i (step S121). Whereas if i is coincident with N (step 
S120; Y), the scheduling unit 15 sets "1" in the variable i 
(step S122). 
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(54) Central policy based traffic management 

(57) A switching node configuring different traffic 
management protocols via a single centralized set of 
policies. The switching node includes a central policy 
repository, a central policy engine, and a central man- 
agement engine. The central policy repository stores a 
single set of policies used to manage a plurality of dif- 
ferent traffic management protocols in a consistent and 
predictable manner. The different traffic management 



protocols may include QoS, NAT, ACL, and the like. The 
central policy Mgine evaluates inbound traffic Hows 
based on the plflcies in the central policy repository, and 
configures onaioj' more traffic management protocol en- 
tities based on a selected policy. The management en- 
gine configures and manages the single sot of policies 
via a common set of commands helping to eliminate iho 
danger of creating conflicting policies that may load to 
unpredictable results. 
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Description 

CROSS-REFERENCE TO RELATED APPLICATION 

(S) 

[0001] This application claims the benefit of U.S. pro- 
visional application No. 60/328,159, filed on October 10, 
2001 , the content of which is incorporated herein by ref- 
erence. 

FIFTD Or THE INVENTION 

[0002] Tho present invention relates generally to traf- 
fic control in a data communications network, and more 
particularly, to configuring different network protocols 
associated with traffic management via a single central- 
ized set of policies. 

BACKGROUND OF THE INVENTION 

[0003] Policy based traffic control has become in- 
creasingly important in data communication networks 
as data traffic competes for limited bandwidth. Policy 
based traffic control generally involves separate, inde- 
pendent interfaces for configuring different traffic man- 
agement protocols. 

[0004] FIG. 1 is a schematic block diagram of a 
switching nodo 9 for policy based traffic control accord- 
ing to conventional mechanisms. The switching node in- 
cludes separate, independent policy engines 11, 13, 15 
and associated interfaces 17, 19, 21 for managing and 
configuring different traffic management protocols. For 
example, a switching node may include a separate pol- 
icy engine for controlling quality of service (QoS), IP fil- 
tering via access control lists (ACL), network address 
translation (NAT), and the like. Each policy engine is as- 
sociated with a control interface used by a network ad- 
ministratorta configure and manage the associated pol- 
icies for a discrete traffic management protocol. 
[0005] In general terms, an inbound packet is proc- 
essed by a first policy engine, such as, a QoS policy 
engine, for a matching policy. If a match is found, the 
matching policy is enforced and the packet is generally 
not processed by the other policy engines. If a match is 
not found, the packet is processed by a next policy en- 
gine for a match. Under existing technology, therefore, 
multiple actions from different policy engines are either 
impossible or difficult to perform for a specific traffic flow. 
It is often desirable, however, to be able to perform such 
multiple actions. For example, it may be desirable to in- 
voke a NAT policy engine for address translation based 
on a source IP address while simultaneously invoking 
the QoS policy engine for assigning a QoS priority to the 
(low based on the same source address. 
[0006] Another problem with the current policy based 
traffic control is that the use of separate, independent 
interfaces for configuring the policies generally requires 
the network administrator to learn and use different 



command sequences for configuring and managing dif- 
ferent policy engines. This may result in the configura- 
tion of conflicting policy rules that may leadto unpredict- 
able results, especially if the configurations are done by 
s different administrators or the same administrator at dif- 
ferent times. 

[0007] Accordingly, there is a need for a mechanism 
for providing and applying a common and consistent set 
of policies to traffic flowing through a data communica- 
io tions network. The mechanism should allow aswitching 
node to enforce a singe policy with multiple actions in a 
consistent manner. 

SUMMARY OF THE INVENTION 

15 

[0008] The present invention is directed to traffic man- 
agement via a single centralized set of policies. Accord- 
ing to one embodiment, the invention is directed to a 
switching node in a data communications network that 

20 includes an input, a repository, a policy engine, and a 
management engine. The repository stores a single set 
of policies for controlling a plurality of different traffic 
management protocols. The policy engine is coupled to 
the input and the repository, and is configured to evalu- 

25 ate an inbound packet based on a policy selected from 
the single set of policies, and configure one or more traf- 
fic management protocol entities based on the selected 
policy. The management engine is coupled to the repos- 
itory and the policy engine. The management engine 

30 configures and manages the single set of policies via a 
common set of commands. 

[0009] According to another embodiment, the inven- 
tion is directed to a method for policy based traffic man- 
agement where the method includes storing in a repos- 

35 itory a single set of policies for controlling a plurality of 
different traffic management protocols. The method in- 
cludes receiving a first packet, retrieving a first policy 
from the repository where the first policy identifies a first 
action for configuring a traffic management protocol en- 

io tity of a first protocol type, and configuring the traffic 
management protocol entity based on the first action. 
The method also includes receiving a second packet, 
retrieving a second policy from the repository where the 
second policy identifies a second action for configuring 

45 a traffic management protocol entity of a second proto- 
col type, and configuring the traffic management proto- 
col entity based on the second action. 
[0010] According to a further embodiment, the inven- 
tion is directed to a method for policy based traffic man- 

50 agement where the method includes storing in a repos- 
itory a single set of policies for controlling a plurality of 
different traffic management protocols, receiving a 
packet, and retrieving a policy from the repository which 
identifies a first and second action for controlling traffic 

ss management protocol entities of a first and second pro- 
tocol type. The method includes configuring the traffic 
management protocol entity of the first protocol type 
based on the first action and configuring the traffic man- 
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agement protocol of the second protocol type based on 
the second action. 

[0011] In an additional embodiment, the invention is 
directed to a method for policy based traffic manage- 
ment where the method includes storing in a repository s 
a single set of policies for controlling a plurality of differ- 
ent traffic management protocols, receiving a packet, 
and searching a policy cache for a policy applicable to 
the packet. If the policy cache does not include an ap- 
plicable policy, the method includes searching the re- « 
pository for a match, and generating and storing a new 
policy in the policy cache. The new policy is selected as 
applicable to a future packet if the repository contains 
no other policies that are also applicable to a future 
packet but are different from the new policy. n 
[0012] It should be appreciated, therefore, that the 
evaluation of traffic via a central policy engine allows the 
configuration of traffic management protocol entities of 
different protocol types, such as quality of service, ac- 
cess control, network address translation, and the like, 2C 
in a consistent and predictable manner. The manage- 
ment of the policies via a common set of commands and 
the storage of the policies in a central repository help 
eliminate the creation and application of conflicting pol- 
icies that could result in unpredictable results. 25 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0013] These and other features, aspects and advan- 
tages of the present invention will be more fully under- 30 
stood when considered with respect to the following de- 
tailed description, appended claims, and accompanying 
drawings where: 

FIG. 1 is a schematic block diagram of a switching 35 
node for policy based traffic management according 
to conventional mechanisms; 
FIG. 2 is a schematic block diagram of a network 
environment including a packet switching node ac- 
cording to one embodiment of the invention; 40 
FIG. 3 is a block diagram of a switching interface in 
one embodiment of the present invention; 
FIG. 4 is a schematic block diagram of the packet 
switching controller providing and applying a com- 
mon, centralized set of simple policies for control- 45 
ling a plurality of traffic management protocols ac- 
cording to one embodiment of the invention; 
FIG. 5 is a more detailed diagram of the switching 
controller of FIG. 4 according to one embodiment 
of the invention; 50 
FIG. 6 is a conceptual layout diagram of various 
types of policy objects provided by a central man- 
agement engine for creating a centralized set of pol- 
icies according to one embodiment of the invention; 
FIG. 7 is a conceptual layout diagram of a central 55 
policy repository according to one embodiment of 
the invention; and 

FIG. 8 is a flow diagram of a central policy based 



traffic management according to ono embodiment 
of the invention. 

DETAILED DESCRIPTION 

[0014] FIG. 2 is a schematic block diagram of a net- 
work environrnji it including a packet switching node 1 0 
according to ft\e embodiment of the invention. The 
packet switching) node may also be referred to as a 
switch, adataiftmmunication node or a data communi- 
cation switch. Tie packet switching node 10 includes 
switching inten^ ;es 1 4, 1 6 and 1 8 interconnected to re- 
spective groups 5f LANs 30, 32, 34, and interconnected 
to one another Over data paths 20, 22, 24 via switching 
backplane 12. The switching backplane 12 preferably 
includes switching fabric. The switching interfaces may 
also be couplajt) to one another over control paths 26 
and 28. 

[0015] The switching interfaces 14, 16, 18 preferably 
forward packeljs jto and from their respective groups cf 
LANs 30, 32, 3(4:|in accordance with one or more oper- 
ative communication protocols, such as, for example, 
media access control (MAC) bridging and Internet Pro- 
tocol (IP) routihg. The switching node 10 is shown for 
illustrative purpoises only. In practice, packet switching 
nodes may include more or less than throe switching 
interfaces. 

[0016] FIG. 3 Is a block diagram of a switching inter- 
face 50 in one embodiment of the present invention . The 
switching interface 50 may be similar, for example, to 



the switching 
ing interface 
pled between 
52. The acces: 
include a medi 



wlacesU, 16, 1 8 of FIG. 2. Tho switch- 
[(deludes an access controller 54 cou 
*ls and a packet switching controller 
I Ctontroller 54, which may, for oxamplo, 
i Siccess controller (MAC), preferably re- 
ceives inbound packets off LANs, performs flow-inde- 
pendent physical and MAC layer operations on the in- 
bound packets and transmits the inbound packets to the 
packet switching controller 52 for flow-depondont 
processing. The access controller 54 also receives out- 
bound packets from the packet switching controller 52 
and transmits the packets on LANs. The access control- 
ler 54 may also; perform physical and MAC layer oper 
ations on the outbound packets prior to transmitting 
them on LANs. 

[0017] The packet switching controller 52 receives in- 
bound packets, classifies the packets, modifies the 
packets in accordance with flow information and trans 
mits the modified packets on switching backplane, such 
as the switching backplane 12 of FIG. 2. The packet 
switching controller 52 preferably also receives packets 
modified by other packet switching controllers via the 
switching backplane and transmits them to the access 
controller 54 forfdrwarding on LANs. The packet switch- 
ing controller 52 nay also subject selected ones of the 
packets to egress! processing prior to transmitting them 
to the access controller 54 for forwarding on LANs. 
[0018] FIG. 4 is a schematic block diagram of the 
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packet switching controller 52 providing and applying a 
common, centralized set of simple policies for coordi- 
nating a plurality of traffic management protocols, such 
as, for example, access control, address translation, 
server load balancing, quality of service, and the like. 
The switching controller 52 includes a central policy en- 
gine 56 coupled to a central management engine 58. 
The central policy engine 56 evaluates the traffic flow 
against the centralized set of policies to perform, from 
a central location, one or more policy actions typically 
performed by separate, independent policy engines. 
I he centralized set of policies include, but are not limited 
to system policies, network policies, access policies, 
services policies, and the like. The one or more actions 
include, but are not limited to packet filtering, packet pri- 
oritizing, address translation, server load balance group 
assignment, and assignment of 802. 1p. TOS, or DSCP 
values. 

[0019] The central management engine 58 may in- 
clude software and/or hardware components to enable 
a network administrator to configure and manage the 
centralized set of policies, With the central management 
engine 58, the network administrator may, from a single 
location and using a common set of commands, create 
policies that manage different traffic management pro- 
tocols. 

[0020] FIG. 5 is a more detailed diagram of theswitch- 
ing controller 52 according to one embodiment of the 
invention The switching controller includes a packet 
buffer 102, packet classification engine 104, central pol- 
icy engine 106, central policy enforcement engine 120, 
central policy repository 100, and central management 
engine 107. The packet classification engine 104, cen- 
tral policy engine 106, central policy enforcement en- 
gine 120, and central policy management engine 107 
arc logical devices that may be implemented in soft- 
ware, hardware, firmware (e.g. ASIC), or any combina- 
tion thereof. It is understood, of course, that FIG. 5 illus- 
trates a block diagram of the packet switching controller 
without obfuscating inventive aspects of the present in- 
vention with additional elements and/or components 
that may be required for creating the controller. These 
additional elements and/or components, which are not 
shown in FIG. 5 are well known to those skilled in the art. 
[0021] The switching controller 52 receives inbound 
packets 1 08. The packets may include, but are not lim- 
ited to, Ethernet frames, ATM cells, TCP/IP and/or UDP/ 
IP packets, and may also include other Layer 2 (Data 
Link/MAC Layer), Layer 3 (Network Layer) or Layer 4 
(Transport Layer) data units. 

[0022] The received packets are stored in the packet 
buffer 102. The packet buffer 102 provides via output 
signal 1 1 0 the stored packets or portions thereof to the 
packet classification engine 104 for processing. 
[0023] The packet classification engine 104 may in- 
clude one or more of a data extractor and a data cache. 
In an alternative embodiment, the data extractor and da- 
ta cache are provided within the packet buffer 1 02. 



[0024] The data extractor is used to extract one or 
more fields from the packets, and to store the extracted 
fields in the data cache as extracted data. The extracted 
data may include, but is not limited to, some or all of the 

s packet header. For example, the extracted data may in- 
clude, but are not limited to, one or more of Layer 2 MAC 
addresses, 802.1 P/Q tag status, Layer 2 encapsulation 
type, Layer 3 protocol type, Layer 3 addresses, ToS 
(type of service) values, Layer 4 port numbers, portions 

10 of the packet body, and/or any other data used for de- 
termining a policy, 

[0025] The extracted data is transmitted to the central 
policy engine 106 via an output signal 112. The central 
policy engine 106 may be similar to the central policy 

'5 engine 56 of FIG. 4. 

[0026] The central policy engine 106 accesses either 
an internal policy cache 1 1 6 or the central policy repos- 
itory 100 for selecting a policy applicable to the packet. 
In accessing the central policy repository 1 00, the cen- 

20 tral policy engine 106 communicates with the repository 
using protocols such as, for example, LDAP. 
[0027] According to one embodiment of the invention, 
the policy cache 116 includes sufficient information for 
applying policies to existing traffic flows without having 

25 to process the entire list of policies in the central policy 
repository 100 for every packet in the traffic flow. The 
information in the policy cache 1 1 6 is specific enough to 
prevent packets for which a different applicable rule may 
exist in the central policy repository 1 00 to be processed 

so by the policy cache 116. 

[0028] The central policy repository 100 may be im- 
plemented in a local memory and/or an external direc- 
tory server with Lightweight Directory Access Protocol 
(LDAP) access. The central policy repository 100 In- 

35 eludes a list of policies that are based on the contents 
of a packet and/or other elements such as, for example, 
time information, port information, and the like. In gen- 
eral terms, policies are rules composed of one or more 
conditions that describe a packet and one or more ac- 

40 tions defining how the packet is to be processed if the 
condition is satisfied. 

[0029] The central policy engine 106 compares the 
extracted packet data with either the policies in the pol- 
icy cache 116 or central policy repository 100. If a match 

45 is found between the condition(s) in the policy and the 
extracted data, the policy engine determines the action 
(s) to be taken on the packet. The action(s) to be taken 
on the packet are transmitted to the central policy en- 
forcement engine 120 via an output signal 11 7. 

so [0030] The central policy enforcement engine 120 en- 
sures that the packet is processed according to the pa- 
rameters defined in theaction(s), In this regard, the cen- 
tral policy enforcement engine 120 interacts with other 
hardware and software elements in the switching node 

55 30 for causing a desired processing of the packet. For 
example, if the policy actions specify that the packet is 
to be transmitted at a high priority, the policy enforce- 
ment engine 120 may direct the packet buffer 102 to 
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place the packet in a high priority queue of an egress 
port. 

[0031 ] The central management engine 1 07 of FIG. 5 
may be similar to the central management engine 58 of 
FIG. 4. The engine 1 07 may be either a dedicated con- 
sole or part of a network management console. A net- 
work administrator accesses the central management 
engine 1 07 for configuring and managing the policies in 
the central policy repository 100 and the central policy 
engine 106. According to one embodiment, the central 
management engine 107 provides a graphical user in- 
terface that provides a common set of commands and 
tools for configuring and managing polices that control 
different network elements such as, for example, QoS, 
NAT, ACL, and the like. The central management engine 
107 also allows a network administrator to test policies 
before they are applied. 

[0032] FIG. 6 is a conceptual layout diagram of vari- 
ous types of policy objects provided by the central man- 
agement engine 1 07 for creating the centralized set of 
policies according to one embodiment of the invention. 
In the illustrated embodiment, the policy objects include 
rule 200 objects, condition 202 objects, action 204 ob- 
jects, service 206 objects, and group 208 objects. Rules 
200 are top level objects including conditions 202 and 
actions 204. According to one embodiment, rules; are 
provided precedence values indicative of an order in 
which the rules are to be applied, 
[0033] Conditions 202 are parameters used to classi- 
fy traffic, and actions 204 are parameters describing 
how to treat the classified traffic. A condition 202 may 
include a service 206 and/or a group 208. A policy serv- 
ice 206 may be used as a shorthand for certain parts of 
a condition, According to one embodiment, a policy 
service 206 is defined by a service name, an I P protocol, 
a source IP port, and/or a destination IP port. For exam- 
ple, a "video" service may be defined as being associ- 
ated with a "UDP" protocol and destination IP port 
number "4500." In another example, a "telnet" service 
may be defined as being associated with a 'TCP" pro- 
tocol and destination IP port number "23." 
[0034] A policy group 208 may be defined by a list of 
IP/MAC addresses, ports, or services. Policy groups al- 
low a network administrator to define conditions for a 
group of address, ports, or services, instead of creating 
a separate condition for each address, port, or service. 
For example, an "engineering" group may be defined as 
a set of particular IP addresses. A "basic services" group 
may be defined as a set of particular services such as 
telnet, FTP, HTTP, and Sendmail. 
[0035] According to one embodiment of the invention, 
the central management engine 1 07 allows the creation 
of policies defining multiple actions for managing differ- 
ent traffic management protocols. For example, a policy 
in the central policy repository 1 00 may indicate that traf- 
fic with a particular source address and a particular des- 
tination address is to have the source address translat- 
ed and receive a high priority. Thus, two different ac- 



tions, a NAT policy action and a QoS policy action, may 
be defined via a (single policy rule. FIG. 7 is a conceptual 
layout diagram of :ho central policy repository 100 ac 
cording to one embodiment of the invention, in th s il us 
s trated embodiment, the repository includes a policy :a 
ble 300 including a list of simple policy rules 30? Asso 
ciated with each policy rule are a precedence nLmber 
304, condition 306, and action 308, The nrcccdcncc: 
number 304 indicates an order in which :ho rules are te 
10 be applied If traffic matches more than one r.jle l ie 
central policy engne 106 uses the rule with ire highest 
precedence. In the illustrated embodiment, rule is col 
matched since it is a subset, or more specific, than the 
higher precedence rule 2. The precedence ordering of 
's the rules helps! eliminate any rule conflicts and ensures 
that the results <>f evaluating a traffic flow against the 
policies is predictable and consistent. 
[0036] The condition 306 for each rule defines param 
eters used for classifying inbound packets. These pa 
20 rameters include but are not limited to individual source 
addresses orgolirce address groups, individual desti- 
nation addresses or destination groups, and individual 
IP protocols 36flfe, individual IP ports 306d, or policy 
service groups 3D6c. 
25 [0037] The action 308 for each rule defines one or 
more operatioqs.jto be performed on the packet and/or 
traffic management protocol entities. The action 308 
may be a filtering action, such as for example, dropping 
or admitting a packet. The action 308 may also be a QoS 
30 action such as, for example, assigning a priority to the 
packet. The acftain 308 may further bo server load bal- 
ancing, sourcejlf destination address translation, map- 
ping ormarkinJflp2.1 P.TOS, or DSC P values, or a com- 
bination of any of the discussed actions. 
35 [0038] FIG. 8 Is a flow diagram of a central policy 
based traffic control according to one embodiment of the 
invention. The process starts, and in stop 400, the pack 
et buffer 102 receives an inbound data packet and 
stores the packet in the buffer In step 402, the packet 
40 classification engine 104 extracts one or more fields 
from the packets. In step 404, the central policy engine 
106 determines Whether the policy cache contains en- 
tries that match the extracted fields of the packet If the 
answer in YES, the central policy enforcement engine 
*s 120 ensures that the policy action indicated in the 
matched entry of the policy cache is enforced. 
[0039] If no match exists in the policy cache 116, the 
central policy engine 1 06 determines in stop 408 whet h 
er there is an exact match of the extracted fields with 
so conditions of a rule in the central policy repository 100 
If the answer is YES, the central policy engine proceeds 
to program, in step 414, the policy cache 116 with the 
condition fields of the matched policy, the fields having 
the values of the corresponding extracted fields. I his 
55 allowsfuturedatapackets with the same extracted fields 
to match the newly programmed ontry in the policy 
cache 116, avoiding another search of the central policy 
repository 100. In step 416, the central policy enforce 
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mcnt engine 1 20 proceeds to take the policy actions in- 
dicated in the matched policy rule. 
[0040] If there is no exact match of the conditions of 
a rule in the central policy repository 100, a determina- 
tion is made in stop 41 0 whether a partial match exists. 
11 the answer is YES, the central policy engine 106 pro- 
ceeds to program the policy cache 116 in step 418 with 
the condition fields of the selected policy, the fields hav- 
ing the values of tho corresponding extracted fields, and 
with a default action. In step 420, the central policy en- 
forcement engine 120 proceeds to take the default pol- 
icy action. 

[0041] If the search of the central policy repository 100 
does not result in even a partial match of the rules, the 
central policy engine 106 proceeds to program the pol- 
icy cache 116, in step 412, with minimal information 
needed to forward the packet. According to one embod- 
iment of tho invention, such minimal information is a 
source address of tho packet, a destination address of 
tho packet, and a default policy action. In another em- 
bodiment of tho invention, the minimal necessary infor- 
mation is simply tho destination address and the default 
policy action. Tho default policy action is enforced by 
the central policy enforcement engine 120 in step 420. 
[0042] The programming of the policy cache 1 1 6 will 
bo best understood when considering the following ex- 
ample. Assume that the central policy repository 1 00 in- 
cludes tho rules depicted in FIG. 7. 
[0043] A first packet received by the central policy en- 
gine 106 Includes the following fields extracted by the 
classification engine 104: 

Source IP - 192.200.200.200 
Destination IP - 10.5.3.4 
Protocol - TCP 
Port - 80 (HTTP) 

[0044] The central policy engine 106 compares the 
extracted information with entries in the policy cache 
116. Assuming for purposes of this example that this is 
a first packet processed by the central policy engine 
106. no entries are contained in the policy cache 116. 
[0045] The central policy engine 106 then proceeds 
to search tho central policy repository 100 for a match. 
Upon a finding of no match in the central policy reposi- 
tory 100, tho central policy engine programs the policy 
cache with a minimal amount of information needed to 
process and forward future similar packets. In one ex- 
ample, tho central policy engine may program the policy 
cache with a source IP address, destination IP address, 
and a default action. The default action in this example 
is tho assignment of a default priority. The entry placed 
in the policy cache is as follows: 

Source IP -192.200.200.200 
Destination IP - 10.5.3.4 
Action - 0 (best effort priority) 



[0046] The central policy engine 1 06 next receives a 
packet that includes the following fields: 

Source IP - 192.200.200.200 
s Destination IP- 192.1 6B. 1.1 
Protocol - TCP 
Port - 80 (HTTP) 

[0047] The central policy engine 106 compares the 
io extracted information with entries in the policy cache 
1 1 6. Upon a no match, the extracted information is com- 
pared against the rules in the central policy repository 
100. Rule 1 matches the packet's source IP address, 
destination IP address, and protocol. However, there is 
is no match in the port information, resulting in a partial 
match with rule 1. 

[0048] In determining an entry for the policy cache, 
the central policy engine 106 ensures that the entry is 
specific enough to prevent packets for which a different 

20 applicable rule may exist in the central policy repository 
1 00 to be processed by the policy cache. In this regard, 
the central policy engine 1 06 determines the number of 
condition fields of the rule that resulted in the partial 
match. Rule 1 that resulted in the partial match includes 

25 four condition fields: source IP address, destination IP 
address, protocol and port. Thus, the entry placed in the 
fast path includes four condition fields although only the 
source IP and the destination IP are needed to forward 
future packets. The value of the four fields is based on 

30 the information extracted from the packet. Accordingly, 
the entry placed in the policy cache is as follows: 

Source IP - 192.200,200.200 
Destination IP - 192.168,1.1 
35 Protocol - TCP 
Port - 80 (HTTP) 
Action - 0 (best effort priority) 

[0049] A next packet received by the central policy en- 
40 gjne 1 06 includes the following fields: 

Source IP - 192.200.200.200 
Destination IP - 192.168.1.1 
Protocol - TCP 
« Port -21 (FTP) 

[0050] The central policy engine 106 compares the 
extracted information with entries in the policy cache 
116 and does not find a match. If, however, the policy 

so cache had been programmed with less than four fields 
in processing the previous packet, a match would have 
resulted in the policy cache, causing the current packet 
to the forwarded without consulting the rules in the cen- 
tral policy repository. 

55 [0051] The central policy engine 106 proceeds to 
search the central policy repository 1 00 and finds an ex- 
act match with rule 1. In determining the entry to be pro- 
grammed in the policy cache, the central policy engine 
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positoiy, the policy engine evaiualing the pack 
et based on a policy selected from the single 
set of policies and configuring one or more traf- 
fic management protocol entities based on the 
selected policy; and 

a management engine coupled to the reposi- 
tory andJthe policy engine, the management en 
gine configuring and managing the single set of 
policieto Via a common set of commands. 

2. The switching node of claim 1 . wherein the single 
set of policies includes a policy identifying two or 
more actions for controlling two or more traffic man 
agement protocols. 

3. The switchjrtg node of claim 1 . wherein the single 
set of policies includes afirst policy identifying a first 
action for qoiitrolling a first traffic management pro 
tocol and a second policy identifying a second ac- 
tion for controlling a second traffic management 
protocol. f!i] 

4. The switchjJifg node of claim 1 , wherein one of the 
traffic nnant»jjjement protocols is quality of service 

5. The switching node of claim 1 , wherein one of the 
traffic nnanajjjement protocols is access control 

6. The switching node of claim 1 , wherein one of the 
traffic management protocols is address transla 
tion. 

7. The switching node of claim 1 further comprising a 
policy cacte coupled to the repository and the pol- 
icy engine for storing a plurality of cached policies. 

8. The switching node of claim 7. wherein the policy 
engine is configured to evaluate the packet based 
on the plurality of cached policies prior to evaluating 
the packet based on the policies in the repository. 

9. The switching node of claim 8, wherein the central 
policy engine selects a cached policy as applicable 
to the packet if no other policies are stored in the 
repository that are also applicable to the packet but 
are different from the selected cached policy 



determines the number of condition fields in the rule that 
resulted in the exact match. The four condition fields of 
the matching rule 1 are then programmed into the policy 
cache. The value of the four fields is based on the infor- 
mation extracted from the packet. The entry placed in 
the policy cache is as follows: 

Source IP - 192.200.200.200 
Destination IP - 192.168.1.1 
Protocol - TCP 
Port -21 (FTP) 
Action - 7 (high priority) 

[0052] The central policy engine 106 next receives a 
packet that includes the following fields: 

Source IP - 192.200.200.200 
Destination IP - 192.168.2.2 
Protocol - UDP 
Port - 300 

[0053] The central policy engine 106 compares the 
extracted information with entries in the policy cache 
1 1 6 and does not find a match. The central policy engine 
106 then proceeds to search the rules in the central pol- 
icy repository 100 and finds an exact match with Rule 
2. The fields in Rule 2 that resulted in the exact match 
are source IP address and destination IP address. Ac- 
cordingly, the entry placed in the policy cache is as fol- 
lows: 

Source IP - 1 92.200.200.200 
Destination IP - 192.168.2.2 
Action - 7 (high priority) 

[0054] Although this invention has been described in 
certain specific embodiments, those skilled in the art will 
have no difficulty devising variations which in no way 
depart from the scope and spirit of the present invention. 
It is therefore to be understood that this invention may 
be practiced otherwise than is specifically described. 
Thus, the present embodiments of the invention should 
be considered in all respects as illustrative and not re- 
strictive, the scope of the invention to be indicated by 
the appended claims and their equivalents rather than 
the foregoing description. 



Claims 

1. A switching node in a data communications, net- 
work, the switching node comprising: 

an input receiving an inbound packet; 
a repository storing a single set of policies for 
controlling a plurality of differenttraffic manage- 
ment protocols; 

a policy engine coupled to the input and the re- 



10. The switching node of claim 8, wherein if no match 
of a policy is found in the repository, the policy en 

so gine is configured to store in the policy cache a pol- 
icy having a destination address of the packet and 
a default action. 

11. The switching node of claim 8, wherein if a partial 
55 match of a policy is found in the repository, the pol- 
icy engine:!? configured to store in the policy cache 
a policy having condition fields of the policy in the 
-epositoryWhere the values of the condition fields 
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arc obtained from the packet, and a default action. 

The switching node of claim 8, wherein if a complete 
match of a policy is found in the repository, the pol- 
icy engine is configured to store in the policy cache 5 
a policy having condition fields of the policy in the 
repository where the values of the condition fields 
are obtained from the packet, and an action indicat- 
Dd by the policy in the repository. 

10 

A method for policy based traffic management com- 
prising: 

storing In a repository a single set of policies for 
controlling a plurality of different traffic manage- '5 
mcnt protocols; 
receiving a first packet; 

retrieving a first policy from the repository, the 
first policy identifying a first action for configur- 
ing a traffic management protocol entity of a so 
first protocol type; 

configuring the traffic management protocol of 
Iho first protocol type based on the first action; 
receiving a second packet; 
retrieving a second policy from the repository, 2$ 
the second policy identifying a second action 
for configuring a traffic management protocol 
entity of a second protocol type; and 
configuring the traffic management protocol en- 
tity of the second protocol type based on the so 
second action, 



searching the repository if the policy cache 
does not include an applicable policy; and 
generating and storing a new policy in the policy 
cache, 

wherein if the new policy is selected as applicable 
to a future packet, no policies are stored in the re- 
pository that are also applicable to the future packet 
but are different from the new policy. 

16. The method of claim 15, wherein if no match of a 
policy is found in the repository, the policy generat- 
ed and stored in the policy cache includes a desti- 
nation address of the packet and a default action. 

17. The method of claim 15, wherein if a partial match 
of a policy is found in the repository, the policy gen- 
erated and stored in the policy cache includes con- 
dition fields of the policy in the repository where the 
values of the condition fields are obtained from the 
packet, and a default action. 

18. The method of claim 15, wherein if a complete 
match of a policy is found in the repository, the pol- 
icy generated and stored in the policy cache in- 
cludes condition fields of the policy in the repository 
where the values of the condition fields are obtained 
from the packet, and an action indicated by the pol- 
icy in the repository. 



A method for policy based traffic management com- 
prising: 

35 

storing in a repository a single set of policies for 
controlling a plurality of differenttraffic manage- 
ment protocols; 
receiving a packet; 

retrieving a policy from the repository, the policy 40 
identifying a first and second action for control- 
ling a first and second traffic management pro- 
tocol entity, respectively, of a first and second 
protocol type, respectively; 
configuring the first traffic management proto- is 
col entity based on the first action; and 
configuring the second traffic management pro- 
tocol entity based on the second action. 



A method for policy based traffic management com- so 

prising: 



storing in a repository a single set of policies for 
controlling a plurality of differenttraffic manage- 
ment protocols; 55 
receiving a packet; 

searching a policy cache for a policy applicable 

to tho packet; 
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[57] ABSTRACT 

A scheduling apparatus and a scheduling method arc capable 
of reading data elements from a plurality of queues in such 
a form that past hysteresis reflects therein. The scheduling 
apparatus comprises a queue hysteresis table for storing .i 
value e_count obtained subtracting the number of data 
elements (packets, in a router) actually fetched out ol the 
queue, from the number of times with which this queue 
becomes a processing target with respect to each queue. The 
apparatus also comprises a scheduling unit lor cyclically 
designating each queue as a processing target, adding 1 h. 
e_count, corresponding to that queue, in the queue hvsu r 
esis table if no d»la elements exist in the queue designated 
as the processing target, consecutively fetching, from the 
processing target queue, the data elements the number ol 
which corresponds to a value of e count correspond inc to 
the queue if the data elements exist in the processing target 
queue, and decrementing the value of e count by tin 
number of fetched data elements. 

10 Claims, 13 Drawing Sheets 
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FIG. 8 is an explanatory diagram showing an outline of 
the queue hysteresis table incorporated into the router in a 
second embodiment; 

FIG. 9 is a flowchart showing operation procedures of the 
scheduling unil provided in the router in the second embodi- 
ment; 

FIG. 10 is an explanatory diagram showing an outline of 
the queue hysteresis table incorporated into the router in a 
third embodiment; 

FIG. 11 is a flowchart showing operation procedures of 
the scheduling unit provided in the router in the third 
embodiment; 

FIG. 12 is a diagram illustrating an example of internet 
working that uses the router; 

FIG. 13 is a block diagram showing functions of a router 
employing a prior art fair queuing method; and 

FIG. 14 is an explanatory diagram showing scheduling 
procedures by the router using the prior art fair queuing 
method. : 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

The present invention will hereinafter be specifically 
described with reference to the accompanying drawings. ; 
First Embodiment 

FIG. 1 illustrates an outline of a configuration of a router 
to which a scheduling method (and a scheduling apparatus) 
of the present invention is applied. A router 10 in a first . 
embodiment is an apparatus for connecting a subnet A to a 
subnet B, and includes, as shown in FIG. 1, a packet 
classifying unit 11, queues 12^12^, and output buffer 13, a 
queue hysteresis table 14 and a scheduling unit 15. Note that, 
the router 10 is constructed so that some queues 12 are . 
created in a memory dynamically in accordance with a 
receiving condition of packets. Therefore, queues 12 1 -12 / , 
are not always exist in the router 10. Although in this 
embodiment, assuming, for the sake of convenience, that the 
router 10 is provided with N queues 12 which functions 4 
independently, the configuration and operation will be dis- 
cussed first. Thereafter, real configuration and operation of 
the router 10 will be discussed. 

The queues 12j-12 w are buffers for temporarily storing 
packets that should be transmitted to the subnet B, and are A 
each made corresponding to transmitting stations (terminals) 
connected to the subnet A. The packet classifying unit 11 
supplies the queues 12 corresponding to transmitting 
addresses contained in those packets with packets received 
from the subnet A. Note that the router 10 in this embodi- 5 
ment is constructed so as to transfer packets (so-called 
internet packet) each having a structure shown in FIG. 2. 
Hence, the packet classifying unit It specifies a queue 12 to 
store the received packet by reading the transmitting termi- 
nal address (transmitting terminal IP address) included in the 5 
header of the received packet. 

Further, the packet classifying unit 11 executes a process 
of rewriting contents of the queue hysteresis table 14 (the 
details of which will be stated later on) in parallel to the 
above-described supplying process of the packets. The out- 6 
put buffer 13 is temporarily stored with the packets within 
the respective queues 12, and the packets in the output buffer 
13 are transmitted in the as-inputted sequence to the subnet 
B. 

The queue hysteresis table 14 is a table the contents of 6 
which are updated by the packet classifying unit 11 and the 
scheduling unit 15. As illustrated in FIG. 3, the queue 



hysteresis table 14 is stored with active Hags (a Hag) and 
empty count n)l»ibers (e__counf) in such a form ibul Uh-m: 
flags and numbers are made corresponding to queue IDs 
defined as data fr>r identifying the queues. 

The packet ! classifying unit 11 rewrites values of the 
active flags a_J(ag within the queue hysteresis table 1-1 in 
accordance with a packet receiving condition. More 
specifically, whesti receiving a packet, the packet classify! tie 
unit 11 reads, as shown in FIG. 4, a transmitting terminal 
, address included in the header of the received packet first 
(step S401). Nfjit, the packet classifying unit 11 specifies a 
queue ID for ^firing the received packet by referring to a 
address-queue |p table which holds the relationship between 
the transmitting ilerminal addresses and the queue IDs, and 
is provided insirle the unit (step S402). Thereafter, the packet 
' classifying unit 11 checks the value of the active lias- 
corresponding to the specified queue II) in the queue hvs 
teresis table 14 (step S403). 

When the value of the active flag is "(I" (step S403;N), I lie- 
packet classifying unit 11 rewrites the active Hag to " I " (step 
1 S404). Then, tlx: packet classifying unit 11 carries out a 
process for storing the received packet in the specilied queue 
12 (step S405). On the contrary, when the active flag is •• 1 " 
(step S403;Y), the packet classifying unit 11 carries nut a 
process for storing the received packet in the specified queue 
i 12 (step S405) without rewriting the active Hug. 

Moreover, the packet classifying unit 11, parallel to 
(independently on) the series of the above described 
processes, perfontns a process for managing receiving, lime 
of the last received packet for each queue II) the active lias 1 , 
i of which is set to "1". Then, the packet classifying unit II 
changes, based on the managing results, the active Hat', 
concerning the queue ID of which the receiving time 
becomes before a time which a predetermined time (such as 
60 sec.) is subHjjclcd from a current time to "0". 

The schedtl]|jjg unit 15 performs control to transmitting 
the packets stoifqe in the queues 12 to the output buffer 13. 
The scheduling tail 15, when executing this control, refers 
to values of the flags a__flag in the queue hysteresis table 14. 
and refers to and updates values of the empty count numbers 
e_count 

Operations of the router and the scheduling unit 15 in this 
embodiment will hereinafter be described specifically. 

FIG. 5 is a flowchart showing operation procedures ol tin: 
scheduling unit 15 after starting up the router. As shown in 
FIG. 5, the scheduling unit 15, when actuating this router. In 
begin with, sets. "1" in variables i and j respectively, and 
initializes the contents of the queue hysteresis table 14 (step 
S101). In step SUM, the scheduling unit 15 sets "0" in all ol 
the flags a_flag and of the empty count numbers e count, 
thereby initializing the queue hysteresis table 14. Moreovei. 
the packet classifying unit 11, after the scheduling unit 15 
has executed step S101, starts executing the above 
mentioned processes (of supplying the respective queues 
with the packets and updating the values of a Hag in (de- 
queue hysteresis table 14). 

After initializing the queue hysteresis table 14, the .sched- 
uling unit 15 judges whether an active Hag a Hag, of the 
queue the queue ID of which is i, is "1" or not (step SI 02). 

If a llagis not "If", (step S102; N), the scheduling unit 15 

executes a process (steps S120--S122) for setting the queue 
ID of the next queue in the variable i. That is, the scbedu linu. 
unit 15 compares the value of the variable i with a maximum 
value N of the queue ID and, if the value of the variable i is 
not coincident with N (step S120; N), adds "I" lo the 
variable i (step S121). Whereas if i is coincident with N (step 
S120; Y), the scheduling unit 15 sets "1" in the variable i 
(step S122). 



